The advancement of technology has led to an increase in network traffic. Since a network is a collective resource, it is often useful for network managers to know which individuals are using a large percentage of the network's bandwidth, thereby causing network traffic. This information, collectively know as top communicator information, can be used in identifying network problems, verifying design solutions, or simply pointing out the individuals who are using a large share of the network.
Networks are often distributed over large areas and the traffic transmitted over the links between individual network nodes is both critical and expensive. Therefore, it is useful to collect a historical database of information relative to the activities taken by the individual nodes and to then gather all of the collected information from multiple nodes at a time when the effects of occupying network bandwidth are diminished. It is also useful to reduce the total amount of data required to derive this desired information.
A typical communication over the network generally involves two hosts, namely a source and a destination. In the interest of uniformity, hereinafter any host that is a source of communication will be referred to as a talker, any host that is a destination of communication will be referred to as a listener, and those hosts that appear in either source, destination, or both in the course of communication will be referred to as communicators. Knowing the talkers and listeners allows the network managers, system administrators, or other users of top communicator information generated by top communicator algorithms, to discover the implied direction of the communications, and to determine which network host is sending the most data (the talker), and which is destined to receive the most data (the listener). As is generally known, on most networks, the listener is the cause of most of the network traffic due to activities such as downloading of data, and other functions. Knowledge of this information can be used to pinpoint the cause of network traffic for future resolution.
The top communicators on a network are simply the network hosts that are actually involved in the most network traffic. However, whether these top communicators actually caused the amount of traffic that they are involved in is not considered in the calculation. Typically, on networks with multiple servers, it can be expected that the servers would be among the top communicators. Additionally, there may be network hosts that the user does not want to consider in the calculation of the top communicators, such as, but not limited to, a management station or key network devices. Further, this excess information may confuse the end user or force desired hosts out of the scope of network use calculation. By removing known, unnecessary hosts, the number of hosts in the scope of the talker calculations can be reduced from the number of unneeded hosts plus the number of desired hosts to only the number of desired hosts.
The Internet Engineering Task Force (IETF) is a standards body that develops and maintains protocols and other standards for the Internet. Among these standards is the Simple Network Management Protocol (SNMP) which is a network management protocol used in IP environments. This standard is used to communicate network management information. The information and protocols utilized for behavior and collection are described in Management Information Bases (MIBs). A MIB is part of the SNMP and is basically a data file which contains a complete collection of all objects that are managed in a network, wherein the objects are variables that hold information about the devices monitored. The prescribed method of collecting historical network data using SNMP is through the User History group of a Remote Monitoring Management Information Base (RMON MIB). As is well known to one of ordinary skill in the art, the User History group is yet one of many groups within the RMON MIB. Other groups include, but are not limited to, the Hosts group, which provides traffic statistics for each network node in a tabular form, and the Host Top N group, which extends the Host table by providing sorted host statistics.
ERMON implementations employ what are commonly referred to as probes. Probes are software processes which run on network devices to collect information about network traffic and store the information into a local MIB located on the communicator. There are differences between the use of either polling specific SNMP MIB data or using RMON MIBs for historical data collection purposes. With SNMP polling, a network management console must continually poll the SNMP probes to obtain MIB information. Gathering this information not only increases congestion on the network, it also places a large burden on the network management console to gather information. Further, there is a variable lag time inherent in any network communication which also affects SNMP queries.
In RMON, however, the probes themselves collect and maintain the historic information. Therefore, the network management console does not need to continually poll probes in order to ensure that this historical information is properly collected. Also, RMON is not affected by the variable qualities of network communications. These benefits provide both a dramatic reduction in network traffic and increased time related accuracy.
Two standard MIBs which describe remote network monitoring are the RMON MIBs, RFC 1757 and RFC 2021. Within RFC 1757 and 2021 MIBs there are a series of methods that presently can be used to calculate network top communicator information.
The Host TopN group of RFC 1757 can be used to calculate the top n communicators on the network; however, it yields only the Media Access Control (MAC) address, also known as the ethernet address, of the network hosts. Additionally, the collection times are not linked to historical collection and the overall data cannot be collected by the User History group since it is in the wrong data format. Further, this method only provides the communicator information. While either the talker or listener information can overlay the traditional communicator information if the implementor chooses to do so, unfortunately, only one piece of the information can be collected with this table. In addition, there is no standard method to communicate to the network manager which type of information is actually collected. Furthermore, there is no way to remove hosts from consideration in the calculations.
The nlHostTable of RFC 2021 can also be used to calculate the top n talkers, listeners, or communicators on the network. This calculation requires that the table be read through SNMP and stored by a management application at specific intervals. Each host seen by the network has an entry in the table, and finding the desired information requires a comparison of all of the hosts that the network has seen. This means that the use of this method requires a relatively large amount of network bandwidth. Additionally, there is a problem if multiple managers desire the same information in that they would either have to share the information over the network through some other means, or causes an increase in the network traffic by calculating the numbers themselves. Further, there is an additional increase in network traffic if multiple time interval calculations are to occur simultaneously.
Therefore, there is a need in the industry for a method of collecting and maintaining historical top communicator information on a communication device which can remove specific hosts from consideration in network activity calculations, provide the exact protocol specific address of the top communicators, yield results of all three types of communication, and, at the same time, utilize minimal bandwidth.